home *** CD-ROM | disk | FTP | other *** search
Text File | 1990-04-27 | 4.3 KB | 100 lines | [TEXT/GEOL] |
- Item forwarded by A33 to A34
-
- Item 2997865 27-April-90 05:37PDT
-
- From: POWERUP.ENG Power Up Software,PRT
-
- To: MACAPP.TECH$ MacApp Technical
- S.FRIEDRICH Friedrich, Steve
- KSI Knowledge Source, V Johnson,PRT
-
- Sub: PostRes() Revisited
-
- Attn: MacApp.Tech$
- Attn: Steve Friedrich
- Attn: KSI
- SentBy: James Plamondon
- Date 4/26/90
- Subject PostRes() Revisited
- From James Plamondon
- To KSI
- CC Steve Friedrich, MacApp.Tech$
-
- Subject: PostRes() Revisited
- Dear Mike,
-
- I like your proposed mechanism of initializing owned objects via calls of the
- form SELF.SetOwnedThing(SELF.MakeThing) in TOwner.IRes(); however, as you
- pointed out, it has its own problems.
-
- Consider a class TFoo, which contains an owned object of class TThing. The
- owned object is refered to via the field fThing. The owned object is created
- via a call to TFoo.MakeThing. The question is — when should MakeThing be
- called?
-
- If the line "fThing := MakeThing;" appears in TFoo.IRes(), then it must be
- true that TFoo contains all necessary information for the creation and
- initialization of the TThing being created. (This would still be a limitation
- even if MakeThing() could be overriden to take additional arguments, as can be
- done in C++, because the arguments would have to be available to TFoo.IRes().)
-
-
- However, as you pointed out, the inheritance tree of TThing may parallel that
- of TFoo — that is, subclasses of TThing may need information provided by
- subclasses of TFoo. For example, TBar (a subclass of TFoo) may own a
- TBarThing which requires knowledge embodied in TBar. This information is not
- available to TFoo.IRes(), because it hasn't been read in yet when TFoo.IRes()
- is called — it is read in by TBar.IRes().
-
- If the information is not available when TFoo.IRes() is called, then it isn't
- available when TFoo.IRes() calls MakePeriod(), either, even though
- MakePeriod() is polymorphic, so that TBar.MakePeriod() is called. Therefore,
- MakePeriod() has to be called from TBar.IRes(), not from TFoo.IRes().
-
- But — what if TBar has a subclass (TFubar), which owns a TFubarThing, which
- requires information read in by TFubar.IRes()? When TFoo.IRes() calls
- MakeThing(), TFubar's MakeThing() will be called, but the information it needs
- will not yet be available. And so the problem cascades down the inheritance
- tree, ad infinitum.
-
- This problem could be resolved by augmenting IRes() with the oft-requested
- PostRes() routine. IRes() would work exactly as it does now — reading in the
- view resource, and doing whatever initialization were possible. The
- initializations done in IRes() are limited not only by the subclassing problem
- described below, but also by the fact that SELF's subviews don't exist when
- IRes() is called on SELF.
-
- Then, after the entire view hierarchy was initialized via IRes(), a post-order
- traversal would be made through the view hierarchy, calling PostRes() on each
- encountered view. PostRes() would then call MakeThing(), and all our problems
- would be over.
-
- A post-order traversal would assure that SELF's subviews would already be
- initialized with PostRes() before PostRes() was called on SELF. This
- complements the in-order traversal used in IRes().
-
- If we really wanted to be general, we could also add a BreadthFirstRes() pass,
- which would assure that all views that were ancestors (or siblings of
- ancestors) of SELF were initialized with BreadthFirstRes() before
- BreadthFirstRes() was called on SELF. Then comes the question, which do you
- do first — the breadth-first pass or the post-order pass? You've got me
- there. If it mattered, it would imply that having these two distinct passes
- was the wrong solution.
-
- Maybe now that the MacApp folks at Apple are actually done with MacApp 2.0
- final (hurray! great job!), and they're laying around the pool wondering what
- to do next, they could tackle the PostRes() issue — one of the few MacApp
- issues one which Curtis Faith and I have found ourselves in agreement [:-)].
- That alone is strong evidence that this really is a useful feature.
-
- Of course, I could be way off base, and the proposed PostRes() routine might
- be just a demonstration of my ignorance. If so, I'd love to be educated by
- somebody as to the Truth about PostRez().
-
- Looking forward to PostRes(), I remain
-
- Yours,
-
- James Plamondon
-
-